Size difference with the dev branch:

not the same command!
    tinygo build -size short -o ./build/test.hex -target=feather-rp2040 ./examples/adafruit4650
    go: downloading tinygo.org/x/tinyfont v0.3.0
drivers/sizes-dev.txt has more commands than drivers/sizes-pr.txt
    tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/bh1750/main.go
 flash                          ram
 before   after   diff          before   after   diff
  16736   16736      0   0.00%    4308    4308      0   0.00% tinygo build -size short -o ./build/test.hex -target=feather-rp2040 ./examples/adafruit4650
  61012   61012      0   0.00%    6176    6176      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/adt7410/main.go
   9468    9468      0   0.00%    4740    4740      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/adxl345/main.go
  13424   13424      0   0.00%    6780    6780      0   0.00% tinygo build -size short -o ./build/test.hex -target=pybadge ./examples/amg88xx
   8580    8580      0   0.00%    4732    4732      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/apa102/main.go
  11584   11584      0   0.00%    6556    6556      0   0.00% tinygo build -size short -o ./build/test.hex -target=nano-33-ble ./examples/apds9960/proximity/main.go
   9668    9668      0   0.00%    4752    4752      0   0.00% tinygo build -size short -o ./build/test.hex -target=itsybitsy-m0 ./examples/apa102/itsybitsy-m0/main.go
   8196    8196      0   0.00%    2304    2304      0   0.00% tinygo build -size short -o ./build/test.hex -target=microbit ./examples/at24cx/main.go
 138668  138668      0   0.00%   40348   40348      0   0.00%

This is great @soypat thank you for getting going on it!

Please see tinygo-org/cmsis-svd-data#1 for some related supporting work.

Yes! I've looked at it and generated the device definitions. I just added a new commit with stubs for machine and runtime and am getting the following error during linking:

$ tinygo build -target=rp2350 -serial=none  examples/blinky1 
ld.lld: error: unable to insert .start_block after .vector_table
ld.lld: error: no memory region specified for section '.ARM.exidx'
ld.lld: error: no memory region specified for section '.text'

I'm not too sure that the ld file you added will actually work with TinyGo. You probably need to have mostly the same symbols in same order as other platforms.

OK, blinky1 now compiles. I am afraid of flashing the resulting .uf2 😅

I've noticed the bootloader is not included in the build pipeline. I can write invalid assembly in it and everything still compiles...

@rminnich I'll leave all functions so far in panic("unimplemented") state. We should focus on getting the bootloader working and setting the LED pin high/low.

@deadprogram @aykevl I'm melding the RP2040 and RP2350 APIs... it's got some design decisions that some may consider questionable. I've managed to reuse a lot of logic between them at the cost of some magic constant weirdness. There are a few cases where code reuse was just not worth it though such as with the peripheral reset. Love to hear your input on how it is coming along.

OK I feel like I've gotten the hang of writing Cortex assembler and understand what is going on with the linker scripts. I cannot however get to the point of flashing the RP2350 correctly- after I flash it the RP2350 enters bootoader mode and appears as a mass storage device ready to get flashed again.

Aha, looks like things have changed since the RP2040. We now have to build a valid IMAGE_DEF, which is a binary blob with specific format.

Working on a a pico binary encoder/decoder https://github.com/soypat/picobin. Raspberry Pi's picotool is missing lots of features to inspect binaries, which makes sense- it's not designed to reverse engineer their stuff.

Also RP2350 documentation on pico binary layout is VERY lackluster compared to their hardware documentation so having code to describe the layout gives me confidence on what exactly is going on.

OK. I've run into a limitation of the debug/elf package. I need to patch the bootloader by extending its length. I'm thinking of adding a elf implementation that can get the job done to https://github.com/soypat/tinyboot.

Note: @aykevl This PR would add aforementioned tinyboot as a dependency of tinygo compiler. I'm in favor of third partying build tools so that others can use the package and find bugs in parallel to the TinyGo compiler.

Edit: progress here: https://github.com/soypat/tinyboot/tree/main/build/xelf

Thanks for all you great work on this! I was able to bodge together enough fixes to build a working RP2350 GPIO out example here: Blinkinlabs@fbb5234

I cheated in several ways to get it to work so it isn't pullable as-is. The main changes were:

• remove the second stage bootloader- the documentation suggests that it's no longer needed unless you have a weird spi flash chip, and elf files generated by the pico 2 sdk don't seem to include it. The functionality has been moved into the boot rom.
• add a stub embedded block right after the isr vector table, so that the boot rom can identify the image. I borrowed this from the rp2350 datasheet. A more complete system like you are describing would include a second block at the end of the image. The elf files generated by the pico 2 sdk include this second block. I think the only function it serves is to verify that the entire image was written into flash, as the default block doesn't include an image checksum.

After disabling some other initialization bits which were causing the image to hang, I succeeded in running a very short that just turns the LED on and off repeatedly.

package main

import (
        "machine"
)

func main() {

    led := machine.LED
    led.Configure(machine.PinConfig{Mode: machine.PinOutput})

    for {
        led.Low()
        led.High()
    }
}

Here's also a very basic python tool for extracting IMAGE_BLOCKs from rp2350 ELF files: https://gist.github.com/cibomahto/790c1a34d6001a088de9bfba6e27ed23

I need to patch the bootloader by extending its length.

@soypat What do you mean by this? It's generally not possible to move stuff in the firmware file after linking.

Would it be possible to write binaries in a similar way that ESP8266/ESP32 binaries are created? So the ELF file is not modified, instead the ELF file is converted to a binary in a custom way that adds the special header.

@aykevl Looking at the esp builder:

I think not, because for the RP2350, the pico SDK generates a normal ELF image, just with some magic headers embedded in it.

For RP2350 ELF output, the pico SDK generates a normal ELF file directly, with one info block tucked between the isr table and the start of program image, and another in a second ELF section, at the end of the program image. The first one needs to include an offset to the second one (which needs to be calculated after the program image size is determined), but the second one points back to the memory address of the first one, which should be fixed. If this is done as a post-processing step, it does require rewriting the ELF file in order to make those two changes. Perhaps the builder could insert a dummy section for the second block, and then patch it with elfpatch? At a glance, this seems like it should also allow UF2 files to be generated from the patched ELF.

However, the datasheet also gives an example of a minimum implementation that doesn't need any post processing, just a simple header that needs to be placed in the first 4k of the image. I've chosen this approach to get a basic output working. The disadvantage of this is that it won't support any of the fancier validation options that the rp2350 boot rom offers, such as image signing or partition support.

However, the datasheet also gives an example of a minimum implementation that doesn't need any post processing, just a simple header that needs to be placed in the first 4k of the image.

That looks like a much simpler way to do it!
This doesn't require any patching or rewriting of the ELF file, right? Just a way to tell the linker to put that magic block at the right position (presumably after the interrupt table).

The first one needs to include an offset to the second one (which needs to be calculated after the program image size is determined),

This can probably also be done by the linker, with some special assembler magic.

However, the datasheet also gives an example of a minimum implementation that doesn't need any post processing, just a simple header that needs to be placed in the first 4k of the image.

That looks like a much simpler way to do it! This doesn't require any patching or rewriting of the ELF file, right? Just a way to tell the linker to put that magic block at the right position (presumably after the interrupt table).

Correct. These 'blocks' each contain a pointer to the next block, in the form of an offset. The rp2350 bootrom uses the offsets to walk through the block chain, and to verify that they form a closed loop back to the first block. The trick is that if you only have one block, you can point it back to itself by specifying a zero offset, so no calculation needs to be done.

For the proof of concept, I gave it an explicit position by modifying the arm linker file: Blinkinlabs@fbb5234#diff-2048f2f7e5dcd7f7efd321f90018d841b002168ec4aa103d33363f4f4f316171R12 .

This is very straightforward, but seems a little invasive to add that for all ARM targets. Another straightforward option is to include a modified version of arm.ld just for the rp2350, but I don't see any other examples that do that and it's probably more difficult to maintain. Maybe there's an assembler directive to put something at the beginning of .text?

For the proof of concept, I gave it an explicit position by modifying the arm linker file: Blinkinlabs@fbb5234#diff-2048f2f7e5dcd7f7efd321f90018d841b002168ec4aa103d33363f4f4f316171R12 .

Actually in my opinion it's fine, if the name is slightly different. Something more generic/descriptive. What about KEEP(*(.after_isr_vector))? Maybe with a short note like /* for the RP2350 */.

What do you mean by this? It's generally not possible to move stuff in the firmware file after linking.

Not without great effort, which I was motivated to do at one point but no longer- Seeing @cibomahto PR that works looks like a good starting point. Let me know what I can do to get this merged ASAP.

I sent a pull request for the changes that I knew how to add properly. I know of at least these issues that are remaining:

• GPIO: Set the new 'isolation' bit for the RP2350 only: Blinkinlabs@fbb5234#diff-92842a5fcd6e32b41bc401586ea33fd04c1cfc107babed817b12118f08372667L129
• Decide what to do for resets- the behavior of the frceoff/frceon bits has changed in rp2350. Commenting them out at least let the image boot: Blinkinlabs@fbb5234#diff-a7f56abb731d6475be3a5d0641c86fe6fd50b065ff75b2d5d5fbf21a71fcb30cL28
• Figure out why the clock init hangs. Commenting it out allowed the image to boot: Blinkinlabs@fbb5234#diff-9e41e0242756386de153301b40712f687ae1925d01da8c6ec477d770c18bc4d8L61